The invention relates to a method, to a provider, and to a system for automated network deployment of cloud services into a network.
In US 2011/0231552 A1, techniques for intelligent service deployment are described. Cloud and service data are evaluated to develop a service deployment plan for deploying a service to a target cloud processing environment. When dictated by the plan or by events that trigger deployment, the service is deployed to the target cloud processing environment in accordance with the service deployment plan.
In US 2011/0296021 A1, enabling service virtualization in a cloud is shown. A service-level specification for information technology services is obtained from a user. The service-level specification is mapped into an information technology specific deployment plan. Information technology specific resources are deployed in accordance with the information technology specific deployment plan to provide the information technology services.
In US 2012/0072597 A1, templates for configuring cloud resources are shown. Examples include encapsulating cloud configuration information in an importable and exportable node template. Node templates can also be used to bind groups of nodes to different cloud subscriptions and cloud service accounts. Accordingly, managing the configuration of cloud based resources can be facilitated through an interface at a computing component. Templates can also specify a schedule for starting and stopping instance running within a resource cloud.
In US 2011/0270721 A1, monitoring application interactions with enterprise systems is described. Reference US 2011/0270721 A1 shows a deployment and distribution plan for deploying and distributing services and applications. Moreover, services may be created by a provider of an enterprise system or by another source trusted by the enterprise to develop secure services to interface with the enterprise system. Applications may be created by third party developers, by the provider, or by others. Once the provider has finished creating a new service for an enterprise system, the provider system may deploy the service to an ecommerce/store system. Similarly, once a developer has completed development of an application, the development system may deploy the application to the store system.
In Hedenlind's, “Network Services and Tool Support for Cloud Environments”, Stockholm 2011, network services and tool support for cloud environments are described. Hedenlind's article shows that virtualization of servers and network infrastructure is an effective way to reduce hardware costs as well as power consumption. Today's cloud systems are often used to handle virtualization of servers but lack the ability of deploy and configure network equipment. Facilitating network equipment configuration within a cloud environment may make it possible to create complete virtual networks along with well known and proven features of cloud computing today.
In H. Yoshida, R. Take, H. Kishimoto and Y. Hibi, Service oriented Platform, a service oriented platform is shown. H. Yoshida, R. Take, H. Kishimoto and Y. Hibi, Service oriented Platform describes a service oriented platform (SOP) as an infrastructure for providing emerging cloud services. As a combination of servers, storage systems, networks and software, SOP is a platform for cloud-era services merging virtualization and operation technologies. SOP design objectives and the architecture for achieving them are discussed with a focus on server-centric virtualization for automatically developing application systems from the viewpoint of servers and an evolution-oriented architecture for extending and upgrading the service platform without interrupting services.
Further, the IBM Tivoli® Service Automation Manager (TSAM) is a known software tool that enables users to request, deploy, monitor and manage cloud computing services.
Resource allocation templates complement the procedural programming model of the Tivoli Services Automation Manager (TSAM) with a declarative element. Resource allocation templates are attached to service nodes and they specify the requirements that these service nodes have on their hosting environment, i.e., only those data center resources that meet the requirements specified in a node's resource allocation template can instantiate the node. Example requirements include the requirement of a specific hardware platform to host the node, specific hardware resources (e.g., 2 CPUs or 4 GB RAM), or specific operating systems. Further, the resource group setting within a resource allocation template allows for the specification of predefined resource pools. In general, any resource classification attribute in the Change and Configuration Management Database (CCMDB) may be used to define requirements. Resources in the CCMDB are classified according to the Common Data Model (CDM), and have attributes that are specific to their class. This allows, for example, for specifying that certain service nodes may be instantiated on physical resources that belong to the TEST pool. Resource allocation templates are used when provisioning higher-level service nodes, e.g., an IBM WebSphere® instance, which have requirements on their hosting environment.
The concept of resource allocation templates creates redundant ways of managing services in TSAM. For example, one can either use a resource allocation template to specify that a WebSphere node requires a pSeries logical partitioning (LPAR), and these LPARs may be provided and managed by some other means. Alternatively, it is possible to write a more elaborate build plan that contains the same knowledge. One can then provision the LPAR and in a next step install the WebSphere node “on top” of it. In the first case, LPARs are CCMDB objects with no TSAM representation. In the second case, LPARs are TSAM service nodes. TSAM itself offers no guidance on how to choose between these two options.
Once actual IT resources are configured and a service node is deployed, this is documented in a resource allocation record. Resource allocation records are records containing information about the resources that are allocated for a specific service component. Consequently, resource allocation records also contain pointers to the respective Configuration Items (CIs) that represent the respective resources in the CCMDB. If, for example, a WebSphere managed node is deployed on a pSeries LPAR, the CI representing this LPAR would be referenced by the resource allocation record attached to the WebSphere managed node in the service topology instance. Each deployed service instance is described by a service topology instance in the data center. There are no points of variability in service topology instances.
TSAM relies on the CCMDB in order to access information about resources in the managed data-center. In addition to read access, TSAM is also able to modify contents of the CCMDB to reflect changes done to the environment through the execution of TSAM management processes. TSAM does not, however, require CCMDB, but rather can either work by itself, or for more advanced functionality, in combination with CCMDB. It is also possible that multiple different resource allocation templates are attached to a node in the service topology template, meaning that the node can be deployed on different kinds of resources.
The execution of management plans, like build or modification plans, is divided into a preparation phase and an execution phase. Operations to be performed in the execution phase are defined by the tasks in the management plan template. The preparation phase is defined through workflows and comprises multiple automated, human/manual, and customizable tasks. Examples for manual tasks are:
1. A topology customization task where the user fixates points of variability in the service topology template.
2. The user can edit co-location settings to define which service nodes may be deployed to shared physical resources, and which ones are to occupy their own individual resources.
3. After having defined the co-location settings, the required number of physical resources have to be assigned by the responsible person, typically the data center administrator. In doing so, the responsible person may honor the constraints in any applicable resource allocation templates.
An automated operation in any management plan is the creation and maintenance of the service topology instance, which may be considered e.g., as the TSAM-internal representation of “real-world” deployed services. All data that is relevant for managing a service is stored and maintained in its service topology instance.
The Open Virtualization Format (OVF) is a standard for specifying virtual appliances. A virtual appliance is a pre-configured and ready-to-deploy unit consisting of one or more Virtual Machines (VMs), the guest OSs and applications running on them, and potentially application data. OVF is a standard that defines how to package these (multiple) software components along with XML-formatted meta-data into a single portable package. The XML meta-data specifies, among other things, the parameters needed to configuring the guest OS and applications. Moreover, using the concept of OVF environments, it is possible to add dynamic run-time parameters that depend on the environment such as IP addresses, network masks, DNS server addresses, etc. These run-time parameters are processed by a helper program called activation engine that is installed on the guest OS where it is launched upon first system startup (see reference Open Virtualization Format White Paper, Feb. 6, 2009 by DMTF).
The OVF format together with an activation engine offers a workable solution for installing even complex solutions, a.k.a. virtual appliances, consisting of multiple Virtual Machines (VMs), their guest OS, applications, and data.
A further aspect is to plan the deployment of cloud services (a term that in the following is used synonymously with virtual appliances). Planning is the task of identifying where in the physical infrastructure a cloud service may be deployed. It further determines the environmental settings that have to be configured for the cloud service to operate correctly in its physical infrastructure. Examples of such environmental settings are the IP addresses of VMs as well as the DNS or LDAP servers to be used. Planning for environmental dependencies also includes more subtle points, such as the configuration of load-balancers so they correctly interpret application semantics and route session traffic to always the same server (see reference Self-Configuration and the OVF Environment, Jul. 14, 2009, at http://blogs.vmware.com/vapp/2009/07/selfconfiguration-and-the-ovfenvironment.html).
To guide the planning process, it may be advantageous to use declarative policies such as resource allocation templates as described above. In the following, a declarative way of expressing security policies is proposed. In particular, IP-level isolation policies, a.k.a. TCP/IP firewalling policies, are considered.
Another aspect of clouds is the management of resources, such as storage, networks, and VMs, and their connectivity and isolation, respectively. A simple connectivity policy may allow any resource to access any other resource. Such a policy may raise, however, security concerns because threats such as viruses, malicious users, or malfunctioning applications can easily propagate between resources.
Recapitulating, conventional enterprise services are designed and deployed on a per instance basis. E.g., components for services may be offered that are then extended and adapted to a specific customer. The customer then manually installs the service, which may be an application, while performing integration and adaptation tasks.